Business case

2025-09-13

EDA

Chiamate suddivise per ora

Per ogni ora di ottobre ho contato il numero di chiamate in ingresso suddividendo per codifica

Analisi terzi di giornata

Non sembrerebbe presente una periodicità ogni 8 ore per tutte le codifiche, tuttavia potrebbe essere utile considerarla nel modello per coprire i casi in cui la componente parrebbe essere significativa (Mercato Libero Retail)

Analisi mezzi di giornata

Applicando la trasformazione \(\Delta_8 Y_t = Y_t - Y_{t - 8}\) si rimuove la periodicità con periodo di 8 ore, permettendoci di vedere più facilmente altre periodicità nei dati.

Anche in questo caso questa periodicità non sembra ugualmente diffusa tra tutte le codifiche, ma risulta utile includerla nel modello.

Analisi giornaliera

Applicando la stessa tecnica di prima, possiamo rimuovere le componenti periodiche con periodo di 12 ore.

Anche in questo caso risulta evidente una componente giornaliera.

Analisi settimanale

Analisi del trend

Rimuovendo anche la componente settimanale ci rimane da analizzare la presenza di un qualche trend.

Non risulta apparente la presenza di un trend. E’ rimasto solo rumore.

Conclusioni EDA

  • La portata dei flussi è sicuramente globalmente influenzata dalla codifica delle chiamate
  • Stagionalità osservate con periodo:
    • 8 ore
    • 12 ore
    • giornaliera
    • settimanale
  • La stagionalità a prima vista non sembrerebbe ugualmente diffusa, ma potrebbe essere presente con intensità proporzionale alla portata complessiva dei flussi della codifica, rendnedola più difficile da osservare nei gruppi con flussi globali inferiori.
  • Non risulta evidente la presenza di un trend

Formalizzazione modello

Componente deterministica

Proposta di modello per il flusso di chiamate: \[ \begin{align} \lambda(c, t) &= e^{q_c + \sum_{i=0}^4 a_i \cos(\omega_i t) + b_i \sin(\omega_i t)} \\ &= e^{q_c}e^{\sum_{i=0}^4 a_i \cos(\omega_i t) + b_i \sin(\omega_i t)} \end{align} \]

  • \(c\) rappresenta la codifica e \(q_c\) è quindi una costante additiva che dipende da \(c\). Regolano il flusso globale della codifica.
  • \(\omega_i = 2 \pi / T_i\) con \(T_i = 8, 12, 24, 168\) rispecchiando i periodi osservati durante l’EDA

Modello

Processo di Poisson non omogeneo con tasso \(\lambda(c, t)\): \[ x_t|c \sim PP(\lambda(c, t)) \]

Ciò implica che dato un intervallo temporale \((t_0, t_1)\) il numero \(Y_{t_0, t_1}\) di chiamate in ingresso segue la distribuzione:

\[ Y_{t_0, t_1}|c \sim \mathcal{P}(\Lambda(c, t_0, t_1)), \quad \Lambda(c, t_0, t_1) = \int_{t_0}^{t_1} \lambda(c, t) dt \]

Inoltre dato il tempo corrente \(s\) il tempo \(T|c, s\) per l’arrivo della prossima chiamata segue la distribuzione: \[ f(t|c, s) = \lambda(c, s + t) e^{-\Lambda(c, s, s + t)} \]

Approccio bayesiano: distribuzione a priori

Ho seguito un approccio bayesiano, pertanto ho posto una distribuzione a priori per tutti i parametri \(q_c, a_i, b_i\) da stimare nel modello. In particolare ho posto una distribuzione a priori normale di media \(0\) e varianza \(0.0784\). \[ q_c, a_i, b_i \sim \mathcal{N}(0, 0.0784) \]

Fitting del modello

Preprocessing dei dati

  • Il modo migliore per estrarre più informazione possibile dal dataset è quello di calcolare per ogni codifica il tempo che intercorre tra ogni chiamata in arrivo espresso in ore per comodità
  • Per non perdermi niente ho tenuto nel dataset anche il tempo tra l’ultima chiamata del 31 ottobre e la fine della giornata e ho aggiunto una colonna per tenermi traccia se il tempo registrato fosse censurato o meno
  • Ho dato a ciascuna codifica una sua colonna dedicata
  • Ho centrato il tempo espresso in ore in modo che avesse media 0

Attenzione!

Purtroppo a causa di una svista durante l’analisi ho involontariamente ignorato i dati del CreditoBusinness. Fortunatamente costituiscono meno dell’1% dei dati e non dovrebbe aver impattato significativamente sulla corretta stima dei parametri. Non ho rieseguito l’analisi corretta a causa dei tempi particolarmente lunghi per l’esecuzione dell’algoritmo (6/7 ore)

Flusso medio per codifica

Ampiezza delle componenti stagionali

Previsione del flusso di ottobre

Performance

La previsione sembra seguire abbastanza bene l’andamento complessivo dei dati ma è ancora molto impreciso. Infatti i dati osservati finiscono all’interno dell’intervallo di confidenza al 95% solo il 76% dei casi. Ciò consiglia che il modello non è abbastanza flessibile da rappresentare adeguatamente l’andamento dei dati.

Come migliorare il modello

  • Rieseguire l’analisi includendo la codifica mancante
  • Analizzare separatamente e indipendentemente le diverse codifiche, in modo da avere le ampiezze delle componenti stagionali potenzialmente variabili tra le diverse codifiche
  • Aggiungere ulteriori componenti stagionali con frequenza più elevata
  • Condurre l’analisi basandosi sul numero di chiamate per ora invece che sui tempi intercorsi tra una telefonata e la successiva

Come sfruttare il modello

Una volta ottenuto un modello soddisfacentte per le chiamate in ingresso si può passare a modellare i tempi di evasione della chiamata. Nel dataset fornito c’è la colonna Durata conversazione che potrebbe essere utile a questo scopo, differenziando potenzialmente l’analisi tra i diversi valori di GESTIONE.

Con questi due modelli si potrebbe sviluppare una qualche funzione di perdita. Per esempio si potrebbe valutare l’impatto economico di una mancata risposta o di tempi di attesa troppo lunghi per il cliente, e l’impatto economico invece dell’assunzione di un determinato numero di persone disponibili a rispondere. Con questa funzione di perdita e con l’incertezza sui flussi e sui tempi di evasione adeguatamente modellati è possibile applicare metodologie teoretico-decisionali per determinare il numero di persone addette alla risposta che minimizza la perdita media.